[Main] [Docs] [Registration] [Installs] [Links]
WHDLoad and the Memory Managment Unit (MMU)
An MMU is contained in the following processors of the 68000 family: MC68030,
MC68040, MC68060. There are also so called EC versions of these processors
which have a broken, out of action MMU. For example, all standard A4000/030
have only an MC68EC030 CPU. On third party accelerator boards this is
different, look in the appropriate documentation to learn about it. As far as
I know, all 68040/68060's ever built into an Amiga are full CPU's containing a
working MMU (because burstmode and Zorro III requires MMU mapping of IO
space). The distinction between a full CPU and a EC version cannot be done by
software (at least in acceptible time). Therefore the user must do this by
setting the right options for WHDLoad.
For the MC68020 there is an external MMU called MC68851, but this is
currently not supported by WHDload.
Features of a MMU and using in WHDLoad
The main purpose of the MMU is to translate logical addresses to physical
ones. This is required for virtual memory and separated address spaces (for
example in a protected multi process system). Another feature is to specify
special properties like Supervisor Only, Write Protected and Caching mode for
every physical address space (on a page base, where a page used in WHDLoad has
a size of 4096 bytes). WHDLoad does not use logical to physical address
translation. But it uses the MMU for memory protection, cache managment and some special features (Snooping, resload_Protect#?).
Memory protection in WHDLoad
On startup, WHDLoad scans the memory list and will build a translation tree
which includes all accessible memory. It marks the following address spaces as
valid and accessible : $0...BaseMem (using the information from the slave),
$dff000...$dff200 (Custom registers), $bfd000...$bff000 (Cia registers) and
the memory used by the Slave and WHDLoad. If a Freezer is found in memory, the
memory used by the Freezer will also be marked as valid. All other memory is
marked as invalid, and therefore every access to such an area (Read or Write)
will create an Access Fault Exception which will end in an appropriate error
requester created by WHDLoad.
Cache managment using the MMU in WHDLoad
The Caches are usually controled via the CacheControlRegister (CACR). With the
MMU this may be finely adjusted because the cacheability can be set for each
memory page separately. On the 68030 a memory page can be Cacheable or
NotCacheable. On a 68040/68060 it can be cachable WriteThrough, cachable
CopyBack, NonCachable or NonCachable Serialized. The area of WHDLoad and the
Slave are always marked as cacheable (WHDLoad=CopyBack, Slave=WriteTrough). If
the MMU is used by WHDLoad, by default the BaseMem area is marked as
NonCachable, and the Data and Instruction Cache are enabled in the CACR. So
the program located in the BaseMem area runs without Caches but WHDLoad and
the Slave use the Caches to improve performance. The Slave can enable (or
disable if previous enabled) the Caches via the function resload_SetCACR. This function may also
modify the MMU tables for the BaseMem area depending on the Cache set.
User control of the MMU handling in WHDLoad
There are 3 different modes how WHDLoad does affect an existing MMU.
- "ignore MMU":
In this mode WHDLoad does not change any MMU related register. This may be
useful if you have running programs which are banging the MMU and you want that
the functionalities of these programs to remain intact (for example a software
freezer like TK).
Warning: Because WHDLoad does not control the MMU itself a lot of
problems are possible. These problems may cause crashes, malfunctions or other
unforseeable misbehaviors. Here a list of existing risks:
- running Enforcer/CyberGuard or a similar tool will lock/crash the machine,
because WHDLoad will create a lot of Hits each time it switches the OS off and
on. These Hits are not bugs of WHDLoad but part of normal operation.
- newer versions of the 68060.library (starting v41.1) will remap the memory
$0-$1000 (the first page) to a Fast memory location using the MMU, in "ignore
MMU" mode this address translation will remain intact, if the installed
program tries to use this area for any DMA actions (e.g. a copperlist in this
area) the results will be unforeseeable, because the CPU will read/write the
Fast memory location while the DMA's the real Chip memory which contains
random data.
- if the running MMU stuff depends on his exception handler ("Access Fault"
exception) the option NoTrapHandler/S
must be activated, otherwise any exception occuring will be handled by
WHDLoad, which will quit the installed program if any unwanted things happen
- if the running MMU stuff uses any memory (exception handler, translation
tree, ...) inside the BaseMem of the installed program, it may crash, because
the BaseMem will be overwritten during executing the installed program
(temporarily)
- in general each program which changes basic functions of the system (using
the MMU) may conflict with WHDLoad ...
- "disable MMU":
In this mode, which is possible only on 68030, the MMU will be switched off by
WHDLoad, no MMU related features are available.
- "use MMU":
In this mode WHDLoad takes full control over the MMU and realizes memory
protection and cache management as explained above.
On the 68030 the default mode is "disable MMU". On the 68040/68060 default is
"use MMU". There are two options to control this behavior. MMU/S enables the MMU feature and must be used on
68030 systems to enable the MMU functionality. NoMMU/S does disable the MMU usage.
"An Enforcer hit is an Enforcer hit, period" (Michael Sinz)
[Main] [Docs] [Registration] [Installs] [Links]